tikv, txnkv: unify the way background goroutines are spawned - #2064

Background jobs used to be started in three different ways: a builtin `go`
statement, `KVStore.Go`, and `KVTxn.spawnWithStorePool`. Each of them tracked
(or failed to track) the goroutine differently, which is the kind of mismatch
that caused pingcap/tidb#57213.

Make `KVStore.Go` the single entry point. It now registers the job with the
store WaitGroup, runs it in the store pool, and rejects new jobs once the store
starts closing, so `Close` waits for background jobs instead of racing with
them. `KVTxn.spawn` and `KVTxn.spawnWithStorePool` collapse into one `spawn`
that goes through it.

Along the way:

- `Spool.Run` returns `ErrPoolClosed` instead of letting the underlying pool
  silently drop the function, so a rejected job is no longer indistinguishable
  from an accepted one. `Spool.Close` is now idempotent.
- `KVTxn.spawn` calls the `Post` lifecycle hook when the goroutine is rejected,
  which keeps it balanced with the `Pre` hook that already ran.
- Callers that prepared state for a background job (`cleanWg`, the async
  pessimistic rollback WaitGroup, the broadcast rate limit) release it when the
  job is rejected, instead of leaving a waiter blocked forever.
- `WaitGroup()` is dropped from the `kvstore` interface used by the transaction
  package and deprecated on `KVStore`.

Foreground fan-out goroutines that the caller joins before returning, such as
`batchExecutor.startWorker` and `KVStore.updateMinSafeTS`, are left as plain
`go` statements: they are not background jobs and do not outlive their caller.

Closes tikv#1510

Signed-off-by: ljluestc <63439129+ljluestc@users.noreply.github.com>